The engine has now been in development for a few years. The initial commit was made on May 4th 2022, so more than two years ago already. The idea of the project at the time was to familiarize myself with a few technologies I never tried, or wanted to improve with.
The main goals were to:
So this is what I did. I started working on this, first adding some math functions in Rust, then adding the most basic of OpenGL code. Just after that, I added a basic WPF editor. Not long after, I had a working basic CMake environment. At this point, on June 6th 2022, I had the basis for what I wanted to do and could expand on it.
An important goal for me was to minimize the dependencies on libraries (not languages), and have fun doing everything, or as much as possible by myself. It is a good way to learn too.
The list of items I allowed myself to use were the following:
GLFW and GLAD are the bare minimum to include OpenGL in a project. ImGUI was added in the beginning to help with debugging runtime engine. It might be removed in the future to respect the true philosophy of this engine. On the other hand, I allowed myself to use the .NET libraries on the editor side in C#, including WPF for the editor window handling.
This had the advantage of making me learn how to use GIT submodules, since GLWF and ImGUI were integrated as GIT submodules. Also, GLAD had CMake files, so I learn to integrate CMake with other CMake projects while building. Note that the GLAD code is downloaded via Python code (using Pip). Here is the first editor version, with a compute shader.
I wanted everything to work easily for a new user, so everything is handled properly through CMake, as long as the user has the proper compilers installed on his machine. A user syncing the repository for the first time just has to launch a single batch file and all the (runtime) dependencies are downloaded and compiled.
In the future, I plan on adding documentation on the different compiler and tool dependencies, such as CMake itself, MSVC and the like. I might add a script to install it all automatically if needed.
At this point in time, I took a hiatus of several months and did not touch the project for a while.
In march of 2023 (the 15th to be specific), I went back to the project. In my mind, the first step to a build pipeline was to make it cross-platform. I then planned on compiling on Linux. The editor, being in C# and very tightly tied to Windows, was not added. A standalone target was created and this builds on both Windows and Linux.
I also added the support for INI files in order to set some configurations in a single place for the engine to read and interpret. The parser is custom, and I can set some paths in there.
Afterwards, I took another pause of several months before going back to the project in August 2023. This time, the goal was to have the build machines (i.e. the Bitbucket Pipelines) build the game (and run tests) on Linux after submits.
I created a Docker image to have a custom image fitted to my needs. Then I pushed the image on Docker and started using it in the Pipelines.
I won't detail all the steps I did, but not long ago I achieve a satisfying state for the pipelines. Depending on the branch different pipelines run.
Here is an example of the Main branch pipeline:
In other pipelines, unit tests are run. The main unit tests internal function is just a very simple function where a test runner can be assigned functions to test and then it runs them.
EXPORT bool CALL UnitTests_RunAllTests(const bool warning_are_errors)
{
SolidSnow::UnitTest::TestRunner test_runner;
test_runner.Register(SolidSnow::UnitTest::Test_SOA_Functionalities);
test_runner.Register(SolidSnow::UnitTest::Test_ThreadingTools_Functionalities);
test_runner.Register(SolidSnow::UnitTest::Test_RuntimeTools);
#if SOLIDSNOW_WITH_ISPC
test_runner.Register(SolidSnow::UnitTest::Test_ISPC);
#endif
return test_runner.Run(warning_are_errors);
}
This function is exposed as a parameter to the executable of the engine. This can be used by the pipeline to run unit tests in general, as well as builind the code.
# run unit tests SolidSnow_Engine_Exe.exe -run_unit_tests
In September 2023, I taught a class in Video Game Physics. I saw it as an opportunity to improve on my engine by doing all my live demonstrations in my custom engine. Since the students had to work in Unity (C#) the solutions were not usable as-is, but the logic and algorithms were.
Before heading in a teaching class involving 3D objects, a mandatory change was for a real camera. For this, since I removed the dependency on GLM, a maths library, I needed to rewrite real matrix maths. The following is an example of suffering:
// specific to transform, this determinant is not general for matrices
MatrixTransform MatrixTransform::Adjugate() const
{
//https://semath.info/src/inverse-cofactor-ex4.html
MatrixTransform out;
const MatrixTransform& m = *this;
out(0, 0) = m(1, 1) * m(2, 2) - m(1, 2) * m(2, 1);
out(0, 1) = m(0, 2) * m(2, 1) - m(0, 1) * m(2, 2);
out(0, 2) = m(0, 1) * m(1, 2) - m(0, 2) * m(1, 1);
out(1, 0) = m(1, 2) * m(2, 0) - m(1, 0) * m(2, 2);
out(1, 1) = m(0, 0) * m(2, 2) - m(0, 2) * m(2, 0);
out(1, 2) = m(0, 2) * m(1, 0) - m(0, 0) * m(1, 2);
out(2, 0) = m(1, 0) * m(2, 1) - m(1, 1) * m(2, 0);
out(2, 1) = m(0, 1) * m(2, 0) - m(0, 0) * m(2, 1);
out(2, 2) = m(0, 0) * m(1, 1) - m(0, 1) * m(1, 0);
out(3, 0) = m(3, 0) * m(2, 1) * m(1, 2)
+ m(2, 0) * m(1, 1) * m(3, 2)
+ m(1, 0) * m(3, 1) * m(2, 2)
- m(1, 0) * m(2, 1) * m(3, 2)
- m(2, 0) * m(3, 1) * m(1, 2)
- m(3, 0) * m(1, 1) * m(2, 2);
out(3, 1) = m(0, 0) * m(2, 1) * m(3, 2)
+ m(2, 0) * m(3, 1) * m(0, 2)
+ m(3, 0) * m(0, 1) * m(2, 2)
- m(3, 0) * m(2, 1) * m(0, 2)
- m(2, 0) * m(0, 1) * m(3, 2)
- m(0, 0) * m(3, 1) * m(2, 2);
out(3, 2) = m(3, 0) * m(1, 1) * m(0, 2)
+ m(1, 0) * m(0, 1) * m(3, 2)
+ m(0, 0) * m(3, 1) * m(1, 2)
- m(0, 0) * m(1, 1) * m(3, 2)
- m(1, 0) * m(3, 1) * m(0, 2)
- m(3, 0) * m(0, 1) * m(1, 2);
return out;
}
Once the mathematics were cleaned up, I could add code to support real cameras, and also different types of camera. I even added an option to switch camera at runtime. Camera code is rather simple on the user side now:
// client code sample for the camera manager CameraManager& cameraManager = CameraManager::GetInstance(); Camera& camera = cameraManager.GetActiveCamera();
The renderer was lacking on every aspect too. I added functionality to have different shaders run at the same time, and improve the control for the user.
For example, I added a function to execute code on all shaders, or on a given shader, based on a shader key that is provided when creating a shader.
// Draw all the shaders
ForEachShader([](const auto& shader)
{
shader.Draw();
})
// Update the mesh of a specific shader
Renderer& renderer = Renderer::GetInstance();
renderer.ExecuteOnShader(m_shaderKey, [this](auto& shader)
{
shader.UpdateMesh(m_mesh);
});
Outside of better control on the shaders, I had to develop the different shaders. After I had single colors one done, I wanted to add texture support.
The problem before I could even draw textures is that I had to be able to import them. So the first thing I did was adding a picture importer in C. Why not C++ ? Because I decided it would be more fun to just do it in C. Given a path, now it is possible to import a bitmap (bmp) file. I used this page to write the code : Bitmap format. So if the picture I want to import is not a bitmap, I have to convert it in another software and then import it.
std::string path = "Actual/Path"; u32 widthOut = 0u; u32 heightOut = 0u; u8* data = SolidSnowPictureImporter.Import(path.c_str(), &widthOut, &heightOut);
The result of this import is having a floor and walls in my little hardcoded demo map. Note that I also added the support for compute shaders to have animated textures (see the balls thrown by the player in the following picture).
One more thing I added after I had some semblance of control over my rendered was to add easy to use debug functions for a user. It uses my debug draw shader, which draws with a single color all the vertices, but also draws the edges of the mesh with a black outline.
#if SOLIDSNOW_DEBUG void DebugDrawLine(const Segment& segment, const Vector3f& color); void DebugDrawCircle(const Vector3f& position, const float radius, const Color& color, const uint32 segment); void DebugDrawDisk(const Vector3f& position, const float radius, const Color& color, const uint32 segment); void DebugDrawSquare(const Vector3f& position, const float halfLength, const Color& color); void DebugDrawSphere(const Vector3f& position, const float radius, const Color& color); #endif
Finally I had some basis to work with, and I could do some physics things! In fact, they were done along the way, so they did not come after, it's just easier to blog about it this way. I added simple collision detection, for example Sphere-Plane collisions, and I can shoot the spheres by pressing a key. The gravity is also applied on the moving bodies.
A particle manager was also added with support for many different types of forces in between them. The simulation was done in 2D for the particles.
There were two difficulties. First was the need for color support per triangle since I wanted to give a single color to each particle, which was a triangle, not just a debug draw with a color for all the mesh. And also the rendering of that many split triangles. I just put them in the same mesh. When new triangles are generated they are appended in an efficient way to the mesh. It could be used for 2D particles in the future but it is more a proof of concept.
After all this was done, I decided to add support for spatial partitions. I added grid support, and then I added QuadTree and Binary Space Partition code. The grid is a bit more trivial than the rest so I do not add any visuals for them here. The QuadTree could be converted into a OctTree, but I did not do it. I can still use the QuadTree in a 3D map in a game with little verticality (using top-view).
After doing the QuadTree, I added Binary Space Partition. Instead of just aligning with the axis X and Y, I chose an angle to minimize the overlap with shapes. Afterwards, I added a varying number of subdivisions, starting from the division that was just made. The goal is to have the same number of elements in each subdivision, with a minimal number of overlaps with the spheres.
I also did that only in 2D, and it can be used in a 3D game. To be honest, splitting the world using planes might prove more complex. If I were to do it, I would probably just go with planes aligned with the X, Y and Z axis.
Another thing I did was to add some more complex shape collisions, but no real mesh collision complexity level. I just added rectangular prism support with any 3D rotation. I show in the next video how I calculate the closest point between the two shapes to know if they collide or not (the red spheres). Also, it proves the debug code works.
Eventually, I incorporated some more features I toyed with, but do not use yet within the engine.
I added some threading tools, and even added them to unit tests for performance testing. I added four main tools:
